perm filename NET.MSG[NET,MRC]1 blob
sn#318457 filedate 1977-11-22 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00008 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 REVISED LIAISON LIST
C00010 00003 MEMORANDUM
C00019 00004 1973
C00020 00005 1974
C00050 00006 1975
C00096 00007 1976
C00144 00008 1977
C00173 ENDMK
C⊗;
REVISED LIAISON LIST
Two Network Liaison Lists are now available at OFFICE-1 for network
use:
<NETINFO>LIAISON.TXT - containing a listing of names addresses,
phone numbers, etc., suitable for producing mailing labels with
some modification.
<NETINFO>LIAISON-SNDMSG.TXT - containing a continuous listing of
sndmsg addresses suitable for online group distribution of
messages to Liaison.
For your information, the NIC maintains the 'official' Arpanet
Liaison List, and additions or changes should be verified by
contacting FEINLER@SRI-ARC. Since any network user may copy these
lists, other versions may be in circulation. Consequently, the NIC
disclaims any responsibility for lists other than those contained
in the files mentioned above. I also urge you to check the NIC
list frequently for recent changes.
NOTE: Some of you have been using Alex McKenzie's very useful
version tailored toward TENEX users. There have been several
changes received at the NIC just recently due to the influx of
Resource Notebook information, so you may want to update that
version, if you have one, or check with Alex.
These liaison lists may be FTPed by any network user. I hope you
will make this known to other users at your sites. (NOTE: If
needed, FTP may be accessed at OFFICE-1 by connecting to OFFICE-1,
then typing:
[@]nicguest <SP> arpa <SP> <CR>
[@]ftp <CR> (There is a 'help' feature available at this
point.)
THE SRI-ARC NETWORK JOURNAL SYSTEM
Many of you have asked whether the SRI-ARC Network Journal System
is available for handling RFC and Group-Note online distribution.
(SEE NIC 22383, RFC 629 distributed Mar. 27, 1974.) The system is
available at present, but its use for distributing Network dialog
is still being reviewed. I will forward any decisions or new
information to you that I receive on this topic.
THE RESOURCE HANDBOOK
The Resorce Handbook is moving along - not quite as fast as I had
hoped, but moving. The response from all of you was great. Thanks
a lot. Some servers had particularly long write-ups or extensive
changes, and were not able to meet my rather stringent deadlines.
I am still aiming for a Fall publication date, and hope that this
will not slip too far. Again thanks for the prompt response.
ARPANET DIRECTORY ERRORS
Due to a variety of problems with the identfile data several
important network individuals were inadvertently omitted - in
particular, the whole BBN-NET group, Col. David C. Russell of ARPA
NMRO, and Prof. Feigenbaum at Stanford. I regret these omissions
and ordinarily would publish an addendum. However, I have not been
able to manage this under the current workload. If others have
been omitted, please let me know.
HARDCOPY DISTRIBUTION
NIC does not officially provide hardcopy distribution of any
documents other than the Arpanet Directory and the Resource
Handbook. However, we still have the reference set of NIC
documents here, and I realize many of you have items missing from
the Station Agent and Liaison collections you have received in the
past. Therefore, I will attempt to supply single papers that are
needed IF copies are availble and IF I can get to it. I want to
emphasize that this is unofficial service and therefore very low on
my priority stack. Group-notes should be requested through the
Group Co-ordinators listed on p.47 of the June 1974 Arpanet
Directory and NIC will ONLY honor requests from Co-ordinators for
these items - again on an unofficial basis and if available.
PROTOCOLS
Protocol Notebooks are no longer available as the supply is
exhausted. Currently there is no mechanism for handling
distributon of protocols to my knowledge. Some alternative
approaches are being considered, but to date no decisions have been
made of which I am aware; therefore, maintenance and distribution
of Protocol Notebooks are in limbo. Again I will attempt to
supply occasional, single protocols on an unofficial, very low-key
basis until some other mechanism is evolved.
STATION AGENTS
The group 'Station Agent' is no longer being maintained by the NIC.
The purpose of the station agent was to maintain the
NIC-distributed station agent collection of hardcopy documents for
local users and to provide host-generated documents to the NIC, and
this activity is no longer being supported. This means that you as
the Network Technical Liaison are the only 'official' host contacts
for Network users, and the official liaison to the NIC for
host-related information.
MEMORANDUM
TO: TECHNICAL LIAISONS
FROM: J. McQuillan
SUBJECT: Host Alive/Dead Logic
DATE: 18 July 1974
This note explains two proposed changes to the host alive/dead
logic used in the IMP, and summarizes the operation of the modified
program.
The current logic defines four states a Host can be in:
UP, SOFT DOWN, TARDY DOWN, and HARD DOWN. The events the IMP
senses are the ready line to the Host going up or down, the
Host being tardy on output from the IMP (more than 30 seconds
to take a message), and the Host sending the IMP a message. Transitions
are as follows:
EVENT: READY READY HOST RECEIVE RECEIVE
\ LINE LINE TARDY MESSAGE HOST GOING
\ UP DOWN FROM DOWN
\←← HOST MESSAGE
STATE
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
UP: HARD TARDY SOFT
DOWN DOWN DOWN
SOFT UP
DOWN:
TARDY HARD UP
DOWN: DOWN
HARD UP UP
DOWN:
We have recently changed the IMP program so that the Host
Going Down message includes status information on why the Host is going
down and when it will be back up. This information is reported in Dead
Host Status messages referring to that Host. (See RFC #611 or BBN
Report 1822 for details.)
This change has stimulated further thinking about the IMP/Host
interface, and there are two more changes which appear to be good
ideas for improving this interface. They are both backwards
compatible with the current conventions.
1. Because the Host Going Down message now contains status
information, Hosts may wish to use this facility to notify the network
of planned down time, but may not be able to ensure that
this is the last message to be sent to the IMP. Unfortunately,
the receipt of another Host message by the IMP must be construed
as an indication that the Host is up, and the status of the previous
outage is discarded. The way we propose to eliminate this problem
is to change the action of the Host Going Down message so that it does
not cause the IMP to declare the Host down, but merely to save the
status information. When the Host drops its ready line, or fails to
take output from the IMP, it will be declared dead.
2. With this change, it is convenient to allow Hosts to come
alive after a scheduled down by asserting their ready line. However,
if the Host has been slow in taking IMP output, its ready line will
be up all the time. Therefore, the Host currently must send the IMP a
message to be declared up. We propose to extend this definition, so
that if the Host accepts a message from the IMP, it will also be
declared up.
These changes will be installed in the network on July 30
or shortly thereafter.
The new states and transitions for a Host will be as follows:
EVENT: READY READY SEND OR RECEIVE HOST
\ LINE LINE RECEIVE HOST GOING TARDY
\ UP DOWN HOST MESSAGE DOWN
\←←
STATE
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
UP: HARD SET STATUS TARDY
DOWN DOWN
HARD UP, UP, UP,
DOWN: CLEAR CLEAR SET STATUS*
STATUS STATUS*
TARDY HARD UP, UP,
DOWN: DOWN CLEAR STATUS SET STATUS
*This can't, of course, happen without the Ready line being up, but
the IMP might detect the input or output befoe detecting the change
in Ready line status.
The IMP will maintain 2 variables per Host:
HIHD - alive/dead status of Host
0 - UP
1 - HARD DOWN
2 - TARDY DOWN
3 - DOES NOT EXIST (no hardware interface, etc.)
4 - NOT INIT (software not running
for this Host - e.g., VDH software)
HDOWN = COPY OF 16 bit status last sent by Host in Host
going down message.
The high order 12 bits give the time the Host will
come back up.
The low order 4 bits give the reason the Host is down:
0-4 reserved for IMP use, 0 = no information
5 Scheduled P.M.
6 Scheduled Hardware Work
7 Scheduled Software Work
8 Emergency Restart
9 Power Outage
10 Software Breakpoint
11 Hardware Failure
12 Not Scheduled Up
13-15 Unused
When the imp receives a message for a Host it will follow
this procedure:
If HIHD=0, deliver the message
ELSE IF HDOWN NOT =0, report HDOWN in Dead Host Status
message
ELSE report HIHD as the 4-bit reason and all
1's as the 12-bit time in the Dead Host Status.
Thus the data in the Dead Host Status message will be:
Reason: 0 Reserved
1 Host's ready line is down - reason unknown
2 Host is tardy in taking output - reason unknown
3 Host does not exist to the knowledge of the NCC
4 IMP software for this Host not initialized
5 Scheduled P.M.
6 Scheduled Hardware Work
7 Scheduled Software Work
8 Emergency Restart
9 Power Outage
10 Software Breakpoint
11 Hardware Failure
12 Not Scheduled Up
13-15 Unused
The other 12 bits of status, the time when the Host is
coming up, are all ones for reasons 1,2,3, and 4, and are otherwise
the time given by the Host. Note reasons 0 and 4 are proposed changes
to the current specification in BBN Report 1822.
1973
∂5-DEC-73 1110 network site NIC
JMB 4-DEC-73 22:25 20400
DNLS USERS' GUIDE
Location: SRI-ARC <IJOURNAL>20400.NLS;xnls
---------------------
1974
∂8-NOV-74 1700 network site NIC
Date: 8 NOV 1974 1700-PST
From: POSTEL at SRI-ARC
Subject: TELNET OPTION RFCs
To: Request-for-Comment-Distribution:
< POSTEL, TELNET-COVER.NLS;2, >, 4-NOV-74 11:38 JBP ;;;;
Request for Comments: 659 Jon Postel
NIC# 31177 SRI-ARC
Online file: [SRI-ARC]<POSTEL>RFC659.TXT 18 October 1974
Announcing Additional Telnet Options
This is to announce the set of Telnet Options defined in Requests For
Comments 651 through 658 (NIC 31154 through 31161) are part of the
offical Telnet Options and should be added to the Protocol Notebook.
RFC 651 is a revision of the Status Option to utilize the subcommand
feature and reduce the number of bits required to convey the status
information. This revised Status Option replaces the previous Status
Option.
The others RFCs (652 through 658) are new Options for controling the
behavior of the format effector characters Carriage Return, Horizontal
Tab, Form Feed, Vertical Tab, and Line Feed.
Your attention is also called to RFC 645 (NIC 30899) "Network Standard
Data Specification Syntax" which was prepared some time ago but has not
received wide circulation.
Unfortunately the Network Information Center can not provide hardcopy
documents. Currently the author is responsible for distribution of RFCs.
The documents are available online as:
[ISI]<DCROCKER>STATUS-OPTION-REVISION.TXT
[ISI]<DCROCKER>NAOCRD.TXT
[ISI]<DCROCKER>NAOHTS.TXT
[ISI]<DCROCKER>NAOHTD.TXT
[ISI]<DCROCKER>NAOFFD.TXT
[ISI]<DCROCKER>NAOVTS.TXT
[ISI]<DCROCKER>NAOVTD.TXT
[ISI]<DCROCKER>NAOLFD.TXT
[SRI-ARC]<POSTEL>RFC645.TXT
[SRI-ARC]<POSTEL>RFC659.TXT (This Announcement)
(If these files are not found online they may have been archived,
in this case the files should be accessable via the "interogate"
command.)
-----------------------------------
∂14-NOV-74 1955 network site NIC
Date: 14 NOV 1974 1955-PST
From: POSTEL at SRI-ARC
Subject: Announcement of RFC 647
To: Request-for-Comment-Distribution:
cc: postel
This is to announce the publication of RFC 647, A Proposed
Protocol for Connecting Host Computers to ARPA-like Networks
Via Directly-Connected Front End Processors, by myself, Jon
Postel, Jim White, and Ginny Strazisar, with the general
agreement of Tom Boynton, Frank Brignoli, John Day, Bob
Fink, Carl Ellison, Eric Harslem, Wayne Hathaway, John
McConnell, Ari Ollikainen, Dave Retz, Al Rosenfeld, Stan
Taylor, and Doug Wells. With that many for it already, I
hope you'll be particularly interested in getting a copy
yourself, and passing it around to others at your site (and
elsewhere).
On-line copies available at OFFICE-1 <NETINFO>RFC647.TXT
(FTP with USER NICGUEST, PASS ARPA) and BBN (105 octal)
<STRAZISAR>RFC647 (USER ANONYMOUS, PASS your name). I'll be
glad to send hard-copy on request (Net mail to map -- or MAP
-- at MIT-MULTICS).
Cheers, Mike Padlipsky
----------------------------------
∂25-NOV-74 1306 network site OFF
JBP 25-NOV-74 10:57 31203 [NWG/RFC# 661]
Protocol Information
Location: OFFICE-1 <GJOURNAL>31203.NLS;xnls
*****Note: [ INFO-ONLY ] *****
---------------------------------
∂26-NOV-74 1400 network site OFF
MAP 26-NOV-74 12:49 31396 [NWG/RFC# 666]
Specification of the Unified User-Level Protocol
Location: OFFICE-1 <GJOURNAL>31396.NLS;xnls
*****Note: [ INFO-ONLY ] *****
---------------------------------
∂26-NOV-74 1732 network site NIC
Date: 26 NOV 1974 1731-PST
From: POSTEL at SRI-ARC
Subject: Announcement of RFCs 661 & 666
To: Request-for-Comment-Distribution:
Two RFCs are now available in online form at Office-1. The first,
RFC 661 (NIC 31203), is an index of protocol information about
current activity with protocols in the ARPA Network. The second,
RFC 666 (NIC 31396), is publication in RFC form of Mike
Padlipskys note on Unified User-Level Protocol.
The RFCs may be reterived from the formatted text files:
[OFFICE-1]<NETINFO>RFC661.TXT
[OFFICE-1]<NETINFO>RFC666.TXT
as well as from the journal using the NIC numbers.
The FTP server program at Office-1 will accept username=NICGUEST and
password=ARPA.
--jon.
---------------------------------
∂11-DEC-74 2202 network site OFF
JBP 11-DEC-74 18:04 31484 [NWG/RFC# 674]
Procedure Call Protocol Documents
Location: OFFICE-1 <GJOURNAL>31484.NLS;xnls
*****Note: [ ACTION ] *****
--------------------------------
∂12-DEC-74 1117 network site NIC
Date: 12 DEC 1974 1117-PST
From: POSTEL at SRI-ARC
Subject: Procedure Call Protocol
To: Request-for-Comment-Distribution:
<GJOURNAL>31484.NLS;1, 12-DEC-74 04:32 XXX ;;;; Title: Author(s):
Jonathan B. Postel/JBP; Distribution: /NAG( [ ACTION ] ) NLG( [ ACTION ]
) NSW( [ ACTION ] ) PI( [ ACTION ] ) ; Sub-Collections: NIC NWG SRI-ARC
NAG NLG NSW PI; RFC# 674; Clerk: JAKE; Origin: < NETINFO,
RFC674.NLS;2, >, 11-DEC-74 17:58 JAKE ;;;;####;
NWG/RFC# 674 JBP 11-DEC-74 18:04 31484
Procedure Call Protocol Documents
Request for Comments 674 Jon Postel
NIC 31484 Jim White
SRI-ARC
12 December 1974
Procedure Call Protocol Documents
Version 2
1
As many of you may know SRI is part of a team working on the National
Software Works project. In the course of our work we have developed a
Procedure Call Protocol to be used between the modules which make up
the NSW. We are interested in your comments on this protocol. Please
foreward your remarks to either: 2
James E. White (WHITE@SRI-ARC) or Jon Postel (POSTEL@SRI-ARC) 2a
Augmentation Research Center
Stanford Research Institute
Menlo Park, California 94025 2b
(415) 326-6200 x2960 (White) or x3718 (Postel) 2c
This note announces the release of the second published version of
several National Software Works (NSW) and Procedure Call Protocol
(PCP) documents. Version 2 is SUBSTANTIALLY different than Version 1;
it and all intermediate, informally distributed PCP documents are
obsoleted by this release. 3
Each of the following documents is available on-line in two forms: as
an NLS file and as a formatted text file. The Journal number (e.g.
24459) refers to the former, of course, and the pathname (e.g.
[SRI-ARC]<NLS>PCP.TXT) to the latter, accessible via FTP using
USER=ANONYMOUS and PASSWORD=GUEST (no account required). Let it be
emphasised that files indicated by pathname of the form
[SRI-ARC]<NLS>name.TXT are ASCII text files not NLS files. 4
The specifications are contained in the following documents: 5
HOST (24581,) "NSW Host Protocol" 5a
This document describes the host level protocol used in the NSW.
The protocol is a slightly constrained version of the standard
ARPANET host to host protocol. The constraints affect the
allocation, RFNM wait, and retransmission policies. 5a1
NWG/RFC# 674 JBP 11-DEC-74 18:04 31484
RFC 674; PCP Announcement
Pathname: [SRI-ARC]<NLS>HOST.TXT 5a1a
PCP (24459,) "The Procedure Call Protocol" 5b
This document describes the virtual programming environment
provided by PCP, and the inter-process exchanges that implement
it. 5b1
Pathname: [SRI-ARC]<NLS>PCP.TXT 5b1a
PIP (24460,) "The Procedure Interface Package" 5c
This document describes a package that runs in the setting
provided by PCP and that serves as a procedure-call-level
interface to PCP proper. It includes procedures for calling,
resuming, interrupting, and aborting remote procedures. 5c1
Pathname: [SRI-ARC]<NLS>PIP.TXT 5c1a
PSP (24461,) "The PCP Support Package" 5d
This document describes a package that runs in the setting
provided by PCP and that augments PCP proper, largely in the
area of data store manipulation. It includes procedures for
obtaining access to groups of remote procedures and data stores,
manipulating remote data stores, and creating temporary ones. 5d1
Pathname: [SRI-ARC]<NLS>PSP.TXT 5d1a
PMP (24462,) "The Process Management Package" 5e
This document describes a package that runs in the setting
provided by PCP and that provides the necessary tools for
interconnecting two or more processes to form a multi-process
system (e.g. NSW). It includes procedures for creating,
deleting, logically and physically interconnecting processes,
and for allocating and releasing processors. 5e1
Pathname: [SRI-ARC]<NLS>PMP.TXT 5e1a
PCPFMT (24576,) "PCP Data Structure Formats" 5f
This document defines formats for PCP data structures, each of
which is appropriate for one or more physical channel types. 5f1
Pathname: [SRI-ARC]<NLS>PCPFMT.TXT 5f1a
1
NWG/RFC# 674 JBP 11-DEC-74 18:04 31484
RFC 674; PCP Announcement
PCPHST (24577,) "PCP ARPANET Inter-Host IPC Implementation" 5g
This document defines an implementation, appropriate for
mediating communication between Tenex forks, of the IPC
primitives required by PCP. 5g1
Pathname: [SRI-ARC]<NLS>PCPHST.TXT 5g1a
PCPFRK (24578,) "PCP Tenex Inter-Fork IPC Implementation" 5h
This document defines an implementation, appropriate for
mediating communication between processes on different hosts
within the ARPANET, of the IPC primitives required by PCP. 5h1
Pathname: [SRI-ARC]<NLS>PCPFRK.TXT 5h1a
EXEC (24580,) "The Executive Package" 5i
This document describes a package that runs in the setting
provided by PCP. It includes procedures and data stores for
user identification, accounting, and usage information. 5i1
Pathname: [SRI-ARC]<NLS>EXEC.TXT 5i1a
FILE (24582,) "The File Package" 5j
This document describes a package that runs in the setting
provided by PCP. It includes procedures and data stores for
opening, closing, and listing directories, for creating,
deleting, and renaming files, and for transfering files and file
elements between processes. 5j1
Pathname: [SRI-ARC]<NLS>FILE.TXT 5j1a
BATCH (24583,) "The Batch Job Package" 5k
This document describes a package that runs in the setting
provided by PCP. It includes procedures for creating and
deleting batch jobs, obtaining the status of a batch job, and
communicating with the operator of a batch processing host. This
package is implemented at the host that provides the batch
processing facility. 5k1
Pathname: [SRI-ARC]<NLS>BATCH.TXT 5k1a
RJE-MODEL (24655,) "The NSW Remote Job Entry Model" 5l
2
NWG/RFC# 674 JBP 11-DEC-74 18:04 31484
RFC 674; PCP Announcement
This document discusses the process of utilizing a batch
processing facility to complete a programming task in the NSW
environment. This same activity in another environment might
utilize a remote job entry system. 5l1
Pathname: [SRI-ARC]<NLS>RJE-MODEL.TXT 5l1a
LLDBUG (24579,) "The Low-Level Debug Package" 5m
This document describes a package that runs in the setting
provided by PCP. It includes procedures for a remote process to
debug at the assembly-language level, any process known to the
local process. The package contains procedures for manipulating
and searching the process' address space, for manipulating and
searching its symbol tables, and for setting and removing
breakpoints from its address space. Its data stores hold
process characteristics and state information, and the contents
of program symbol tables. 5m1
Pathname: [SRI-ARC]<NLS>LLDBUG.TXT 5m1a
TBH (24656,) "NSW Requirments on Tool Bearing Hosts" 5n
This document discusses the environment needed in the tool
bearing host and the interfaces to the operating system
components by various PCP packages. 5n1
Pathname: [SRI-ARC]<NLS>TBH.TXT 5n1a
BOXES (24584,) "Black Boxes in PCP" 5o
This document describes the transliteration of the black boxes
defined by Millstein and Warshall into the setting provided by
PCP, especially the File Package and the Executive Package. 5o1
Pathname: [SRI-ARC]<NLS>BOXES.TXT 5o1a
The document on the Host level protocol, HOST, is a suggestion for
some restrictions on the regular ARPANET host protocol for use in NSW,
this topic has little impact on the remainder of the NSW protocols.
The reader is urged to begin with the major Procedure Call Protocol
documents. 6
The document on PCP is the place the interested reader should start.
It gives the required motivation for the Protocol and states the
substance of the Protocol proper. 7
3
NWG/RFC# 674 JBP 11-DEC-74 18:04 31484
RFC 674; PCP Announcement
The reader may then proceed to the next three documents: PIP, PSP and
PMP. The latter has the most relavence to the casual reader; the
programmer faced with coding in the PCP environment should read all
three. 8
The three documents PCPFMT, PCPHST, and PCPFRK specify low level
details of the communication formats and are of interest only to PCP
implementers. 9
The documents EXEC, FILE and BATCH describe procedure packages to be
implemented as appropriate to provide the services of the
accounting/status/usage statistics subsystem, the file subsystem or
batch processing subsystem respectively. 10
The document RJE-MODEL describes how a user would utilize various
tools in the NSW in the process of carrying out tasks he might in the
absence of NSW achieve using a remote job entry system. This should be
read with the document on BATCH.
11
The LLDBUG package specifies a debugging package that operates in the
PCP environment. 12
The document called BOXES describes a mapping between the PCP
mechanisms and the File Package procedures and the Black Boxes needed
by the Works Manager. 13
The document TBH speaks to the requirements placed on the Tool Bearing
Host. This document indicates how and where various PCP packages
interface to an operating system. 14
--------------------------------
∂17-DEC-74 0921 network site NIC
Date: 17 DEC 1974 0828-PST
From: CERF at SRI-ARC
Subject: RFC 675 (NIC 31505) Internetwork Protocol
To: Request-for-Comment-Distribution:
This note announces the release of RFC 675,
'Transmission Control Program Specification'
which defines an internetwork protocol for inter-
process communication. Copies of the spec may be
obtained by sending your mailing address to
CERF at ISI along with a request for a copy.
I have intentionally not sent it out to everyone
because it is about 50 pages long. An on-line
copy without figures is in <CERF>TCPSPEC8.txt at ISI. It may be TCPSPECx.TXT
bythe time you see it.
Vint Cerf
--------------------------------
∂20-DEC-74 1757 network site NIC
JBP 19-DEC-74 14:25 31524 [NWG/RFC# 678]
Standard File Formats
Location: SRI-ARC <GJOURNAL>31524.NLS;xnls
*****Note: [ INFO-ONLY ]
(Secondary Distribution Copy from JBP)*****
---------------------------------
1975
∂11-FEB-75 0215 network site NIC
Date: 11 FEB 1975 0158-PST
From: FEINLER at SRI-ARC
Subject: Hostname Change for USC-ISIA and NIC Services
To: NETWORK-LIAISON-GROUP:
cc: feinler
This is to inform all network liaison that the hostname USC-ISIA has
been changed back to USC-ISI per request of ARPA. Please make the
necessary changeover.
....................................................................
NIC SERVICES
ONLINE LISTS
Since there are many new liaison and hosts on the network, I would
like to point out to the new people that there are currently three
files maintained by the NIC available for FTP from OFFICE-1 (Host 43
dec, 53 oct.) by network users. These are:
<NETINFO>HOSTS.TXT
An ASCII text file that lists official ARPA Hostnames. (See
RFC 625). This file is updated each week if neW information
is received. It is available via FTP to any Arpanet user.
Each Liaison is responsible for seeing that its local hostname
table uses these names.
If new hosts are added to the Network at your facility
please notify Jake Feinler (FEINLER@SRI-ARC) as to what the
new hostname will be.
<NETINFO>LIAISON.TXT
An ASCII text file that lists for each Technical Liaison his
name, U. S. mail address, network mailbox address, phone, and
the host(s) for which the listed individual is liaison.
Several people have modified their own copy of this file to
produce mailing labels.
<NETINFO>LIAISON-SNDMSG.TXT
A list of known network mailbox addresses of the Technial
Liaison suitable for use as a sndmsg group distribution list.
In the near future we hope to receive a copy of the Network
Principal Investigators from ARPA. This will be made into lists
similar to the Technical Liaison lists mentioned above, and will be
available for all to use. A separate notice will be sent out when
this is available.
ONLINE RFCs
All current RFCs are maintained as text files in the directory
<NETINFO> at OFFICE-1 (Decimal 43) and can be FTPd by using the
pathname <NETINFO>RFCnnnn.txt where nnnn = the appropriate RFC
number. Persons wishing to be notified each time an RFC is received
and posted in <NETINFO> should notify Jon Postel (POSTEL@SRI-ARC)
and request to be put on the RFC notification list.
RFCs issued since June 1974 are maintained online by the NIC for
at least 21 days from the date of last access. This is a long
enough time to allow most interested parties to obtain a copy.
If an RFC is not accessed for 21 days, it is automatically
archived and must be retrieved by Jon Postel (POSTEL@SRI-ARC) or
Jake Feinler (FEINLER@SRI-ARC) via sndmsg request.
RFCs issued before June 1974 are not available online mainly
because many of them were never entered online in the first
place. The NIC has master copies of most old RFCs, and we are
currently investigating ways to make them more readily available
in hardcopy form to Arpanet users.
CURRENT NETWORK PROTOCOLS
A hardcopy version of the ARPA Network Current Network Protocols can
now be obtained from the U. S. Dept. of Commerce, National Technical
Information Service (NTIS), 5285 Port Royal Road, Springfield, Va.
22161, or from the Defense Documentation Center (DDC), Cameron
Station, Alexandria, Va. 22314. This document contains current
network protocols in use as of Dec. 1, 1974. Its order number is:
AD A003890, $12.25 for hardcopy and $2.25 for microfiche.
NOTE: Unfortunately this volume does not contain the latest
version of BBN 1822. The latest 1822 can be obtained from Carol
Kidston of BBN (KIDSTON@BBN).
RESOURCE HANDBOOK
The hardcopy version of the Resource Handbook is limping along, but
progressing. Each SERVER host will be given a chance to peruse its
write-up briefly before going to press. We will not be able to do
major rewrites, but will try to change wrong data and minor
inconsistencies. Another memo on this topic will be issued soon.
The online NIC/QUERY version of the Resource Handbook is available
at OFFICE-1. To access connect to OFFICE-1, then type:
[@]login nicguest arpa <SP><CR>
[@]nic <CR>
NOTE: The same guest account can be used for FTP purposes.
It cannot, however, be used to access NLS at OFFICE-1.
The online version of the Resource Handbook is also being updated,
but it will be awhile before it is current.
ARPANET DIRECTORY
Arpanet users who need extra copies of the June 1974 Arpanet
Directory may obtain them from Jake Feinler (FEINLER@SRI-ARC). A
new hardcopy directory is slated to follow the hardcopy Resource
Handbook.
NOTIFYING USERS OF NIC SERVICES
The Liaison are currently the channel by which Network users are
notified of NIC services. I am aware that this is not an adequate
distribution mechanism, but hope that all of you will do what you
can to inform users at your hosts that the above services are
available.
---------------------
∂27-FEB-75 0320 network site NIC
Date: 27 FEB 1975 0259-PST
From: FEINLER at SRI-ARC
Subject: SRI-ARC Name and Host Address Changes
To: NIC-Distribution:
After Friday (2-28-75) SRI-ARC, (host address 2 dec., 2 oct.) will no
longer exist as such on the Arpanet. The Stanford Research Institute,
Augmentation Research Center will continue to manage the Knowledge
Workshop Utility (OFFICE-1), to participate in the National Software
Works Project, and to maintain the Network Information Center (NIC).
The PDP-10 host computer will be removed and will eventually be
replaced with a PDP-11 whose host name and host address are presently
undertermined. Personnel of Stanford Research Institute Augmentation
Research Center will be working in one of two places - members of the
research and development staff and of the NIC will be working at
BBN-TENEXB (Host address 49 dec., 61 oct.) while members of the
Knowledge Workshop Utility will be working primarily at OFFICE-1 (host
address 43 dec, 53 oct.).
Personnel with mailboxes at OFFICE-1 are:
Douglas C. Engelbart (ENGELBART@OFFICE-1)
James C. Norton (NORTON@OFFICE-1)
James H. Bair (BAIR@OFFICE-1)
Robert N. Lieberman (LIEBERMAN@OFFICE-1)
Ray Panko (PANKO@OFFICE-1)
Martin E. Hardy (HARDY@OFFICE-1)
Dave Hopper (HOPPER@OFFICE-1)
Susan Roetter (ROETTER@OFFICE-1)
Sandy Johnson (JOHNSON@OFFICE-1)
Rod Bondurant (BONDURANT@OFFICE-1)
Dean Meyer (MEYER@OFFICE-1)
Jeanne Beck (BECK@OFFICE-1)
Jeff Peters (PETERS@OFFICE-1)
Marcia Keeney (KEENEY@OFFICE-1)
Rene' Ochoa (OCHOA@OFFICE-1)
Dirk Van Nouhuys (VANNOUHUYS@OFFICE-1)
Jeanne Leavitt (LEAVITT@OFFICE-1)
Personnel with mailboxes at BBN-TENEXB are:
Richard W. Watson (WATSON@BBNB)
Charles H. Irby (IRBY@BBNB)
James E. White (WHITE@BBNB)
Jon Postel (POSTEL@BBNB)
Elizabeth 'Jake' Feinler (FEINLER@BBNB)
Elazabeth Michael (MICHAEL@BBNB)
Karolyn Martin (MARTIN@BBNB)
Joe Ehardt (EHARDT@BBNB)
Ken Victor (VICTOR@BBNB)
Harvey Lehtman (LEHTMAN@BBNB)
Dave Maynard (MAYNARD@BBNB)
Joan Hamilton (HAMILTON@BBNB)
Don Andrews (ANDREWS@BBNB)
Adrian McGinnis (ADRIAN@BBNB)
Robert Belleville (BELLEVILLE@BBNB)
Ann Weinberg (WEINBERG@BBNB)
Kirk Kelley (KELLEY@BBNB)
The directories NICGUEST and NETINFO will still be maintained at
OFFICE-1 along with the public files available for NIC users such as
the official hostname file, <NETINFO>HOSTS.txt. All network
correspondence concerning the NIC, however, should be addressed to
FEINLER@BBNB.
Mailboxes should be set up by early next week, and we hope the
transition will go smoothly. Please inform users at your host and make
the appropriate host table changes.
--------------------------
∂27-FEB-75 2255 network site NIC
Date: 27 FEB 1975 2255-PST
From: POSTEL at SRI-ARC
Subject: RFC INDEX for 1-JUN-74 thru 1-FEB-75
To: Request-for-Comment-Distribution:
cc: postel at SRI-ARC, Feinler at SRI-ARC
There is an index of Requests For Comments (RFCs) issued in the
period 1 June 1974 through 1 February 1975 in the online sequential
ACCII text file named RFC-INDEX.TXT in the directory <NETINFO>
at Office-1. This file may be pulled from Office-1 using FTP by
supplying the FTP username ANONYMOUS and password GUEST. the pathname
is <NETINFO>RFC-INDEX.TXT.
--jon.
------------------------------
∂27-FEB-75 2351 network site NIC
JBP 27-FEB-75 19:19 25510
RFC Index for 1-JUN-74 to 1-FEB-75
Location: SRI-ARC <HJOURNAL>25510.NLS;xnls
*****Note: [ INFO-ONLY ] *****
------------------------------
∂1-APR-75 1418 network site BBN
Date: 1 APR 1975 1718-EDT
From: MCKENZIE at BBN-TENEX
Subject: Scheduled Network Additions
To: NETWORK-LIAISON-GROUP:
cc: mcquillan, santos, clements, ncc, hbrown, walden, heart,
cc: neigus, levin, malman, walker at ISI, pearce at ISI
In a previous message to liaisons I announced that IMP #56 would be
installed at NYU in late February. That installation did not take
place due to a serious fire in New York telephone company facilities.
Also, in the most recent version of BBN Report No. 1822, Stanford
Medical Center is shown as a Very Distant Host connected to the
Tymshare TIP (#43) with the decimal Host address 107; this
connection has existed for about one week. However, it has now been
decided to install IMP #56 at the Stanford Medical Center, and to
connect the Stanford Medical Center Host to this IMP as a local
Host, thus removing the VDH connection. This change will take place
either this weekend or early next week. Please adjust Host address
tables accordingly.
IMP #57 will be installed at the National Security Agency (NSA)
on or about April 10. This IMP will be equipped with one Host
interface (decimal address 57).
We anticipate addition in the near future of a new Host interface
to the CCA TIP (#31) which will have decimal address 223.
An IMP will be installed at NYU in approximately mid-May; no
IMP number has as yet been assigned to this machine.
Alex McKenzie
Network Control Center
--------------------------------
∂18-APR-75 1411 network site BBNB
Date: 18 APR 1975 1711-EDT
From: POSTEL at BBN-TENEXB
Subject: RFC 685 Available
To: [bbnb]<postel>Request-For-Comments.List:
This is to announce the availablity of Request for Comments 685
on line at Office-1.
Response Time in Cross-network Debugging
M. Beeler
The pathname is <NETINFO>RFC685.TXT at Office-1
The file can be pulled via FTP using the user name
ANONYMOUS and password GUEST.
--jon.
-----------------------------
∂11-JUN-75 2340 network site BBNB
Date: 12 JUN 1975 0226-EDT
From: FEINLER at BBN-TENEXB
Subject: LBL is up as a New Server
To: NETWORK-LIAISON-GROUP:
The following is a note that Dennis Hall and Eric Beals of LBL
have asked me to distribute for them. Jake
....................................
Hi. The Lawrence Berkeley Laboratory (LBL), an ERDA spondored national
laboratory, is now up and operational on the ARPANET. We have some
excess CDC 7600 time which is available at cost to appropriately
authorized users. If you are interested please contact:
Eric Beals
Lawrence Berkeley Laboratory
Building 50B, Room 3238
Berkeley, California 94720
(213) 843-2740 ext 5351
Yours truly,
Eric Beals
User Services
Mathematics and Computing
........................................
Please pass the word along to any users at your host that might
be interested
-----------------------------
∂17-JUL-75 2357 network site BBNB
Date: 18 JUL 1975 0257-EDT
From: POSTEL at BBN-TENEXB
Subject: NEW Requests for Comments
To: [bbnb]<postel>Request-For-Comments.List:
This is to announce that there are several new Requests for Comments
now available on line at Office-1 in the <netinfo> directory.
These documents are text fies (not nls files) and can be obtained by
using the file transfer protocol. The Office-1 ftp server accepts the
username NICGUEST and password ARPA (no account is necessary). The
documents are in the directory <NETINFO> with file names of the form
RFCnnn.TXT where nnn is the Request for Comments number. Thus the
pathname for request for comments number 703 is:
<NETINFO>RFC703.TXT
The new documents are:
RFC 695 "Official Change in the Host-Host Protocol" Mark Krilanovich
RFC 696 "Comments on thr IMP/HOST Protocol Changes" Vint Cerf
RFC 697 "CWD Command of the FTP" Jim Lieb
RFC 703 "July 1975 Survey of Telnet Servers" Doug Dodds
There is also an update index of recent requests for comments (640-703)
under the pathname: <NETINFO>RFC-INDEX.TXT
--jon.
------------------------------
∂18-JUL-75 0236 network site SRI
Date: 18 JUL 1975 0235-PDT
From: GEOFF at SRI-AI
Subject: New TELNET Protcol at SAIL
To: bh at SAIL
cc: jbr at SAIL
It seems that you guys don't turn off the ECHO when asking things
like passwords and the such. Supposedly this is suppose to happen...
(It also doesn't turn off ECHO on the Old Telnet protocol
either).
------------------------------
∂25-JUL-75 1057 network site BBNB
Date: 25 JUL 1975 1358-EDT
From: POSTEL at BBN-TENEXB
Subject: Request for Comments 698
To: [bbnb]<postel>Request-For-Comments.List:
Request for Comments 698 is now on line at Office-1. Files may be pulled
from Office-1 via FTP using username NICGUEST and password ARPA. The
pathname for the document is <NETINFO>RFC698.TXT
RFC 698 "Telnet Extended ASCII Option" Tovar
--jon.
-------------------------------------------
∂16-SEP-75 2242 network site BBNB
Date: 17 SEP 1975 0141-EDT
From: POSTEL at BBN-TENEXB
Subject: RFC 704
To: [bbnb]<postel>Request-For-Comments.List:
RFC 704 "IMP/Host and Host/IMP Protocol Change" by Paul Santos is now
available online at Office-1. The document may be copied via FTP using
the username NICGUEST and password ARPA. The pathname is:
<NETINFO>RFC704.TXT
--jon.
------------------------------------------
∂25-SEP-75 1213 network site BBN
Date: 25 SEP 1975 1424-EDT
From: MCKENZIE at BBN-TENEX
Subject: Message Forwarded on Behalf of Steve Walker, ARPA
To: NETWORK-LIAISON-GROUP:
cc: walker at ISI, brownfield at ISI
To all ARPA Contractors:
To put to rest any concerns you might have about billing
for ARPA network utilization as described in the recent DCA
letter (and as clarified in the preceeding Netnews item):
All charges incurred by contractors utilizing the network
will be paid by the government sponser of that contractor.
ARPA will fund directly to DCA for all network related
charges associated with its contractors participation on the ARPAnet.
Steve Walker, ARPA
-----------------------------
∂25-SEP-75 1214 network site BBN
Date: 25 SEP 1975 1357-EDT
From: MCKENZIE at BBN-TENEX
Subject: ARPANET Management Transition
To: NETWORK-LIAISON-GROUP:
cc: brownfield at ISI, walker at ISI
Each ARPA Network IMP or TIP site has recently received a
letter from the Defense Communications Agency on the subject of
ARPANET Management Transition. A copy of that letter is reproduced
below, but the second paragraph has been somewhat modified to clear
up an apparent point of confusion.
In the very near future we will distribute copies of Enclosure 1
to the DCA letter by this same mechanism.
The entire text of this note has been read and approved by both ARPA
and DCA, and I am sending it on their behalf.
Alex McKenzie
Network Control Center
FROM: Defense Communications Agency
Washington, D.C. 20305
SUBJECT: ARPANET Management Transition
1. The operational management of the ARPANET was transferred
from the Defense Advanced Research Project Agency to DCA on
1 July 1975. Enclosure 1 is a memorandum of policy for the
utilization of ARPANET. Enclosure 2 is a copy of the ARPANET
Management Transition Plan which gives a detailed description
of the network.
2. The ARPANET backbone is now being funded through the
Communications Services Industrial Fund (CSIF), managed by
DCA. Monthly billings for ARPANET services will be prepared
by the Defense Commercial Communications Office (DECCO),
located at Scott AFB, Illinis 62225. The first billing is
expected to be completed during September 1975, and will be
retroactive to 1 July 1975. All subsequent billings will be
monthly. The FY 1976 monthly billing rate will be $4,900
for each TIP or IMP. A one percent overhead charge will be
added to this monthly billng rate. It should be noted that
DECCO will not bill the individual contractors such as ISI,
MITRE, etc. but will bill the sponsor of the IMP or TIP,
e.g. ARPA will be billed for all the ARPA-sponsored nodes.
3. A sponsors group consisting of government representatives
will be established with the first meeting scheduled for 21
October 1975. The purpose of the group is to provide a vehicle
for coordinating proposed network changes which may impact
sponsors and users, and to exchange ideas and information on
network operations and user activities. All network users will
be represented by their government sponsor.
4. Questions regarding the ARPANET should be directed to
the ARPANET Management Branch Code 535, AUTOVON 222-6175 or
222-6176, Commercial (202) 692-6175 or 692-6176.
-------------------------------
∂30-SEP-75 0719 network site BBN
Date: 30 SEP 1975 1009-EDT
From: MCKENZIE at BBN-TENEX
Subject: ARPANET Management Transition - Enclosure 1 to DCA Letter
To: NETWORK-LIAISON-GROUP:
cc: brownfield at ISI, walker at ISI
Following is the text of "Enclosure 1" to the Defense Communications
Agency letter on the subject of ARPANET Management Transition. The
text of that letter has been transmitted by this mechanism previously.
The entire text of this note has been read and approved by both ARPA
and DCA, and it is being distributed by me on their behalf.
Alex McKenzie
Network Control Center
FROM Defense Communications Agency
Washington, D.C. 20305
SUBJECT: Policy for ARPANET Utilization
1. PURPOSE: This document prescribes the policy of the
Defense Communications Agency concerning utilization of
ARPANET.
2. APPLICABILITY: This policy applies to all users of
the ARPANET.
3. DEFINITIONS:
a. INTERFACE MESSAGE PROCESSOR (IMP). A store and
forward packet switch which will accommodate up to four
host computers.
b. TERMINAL INTERFACE PROCESSOR (TIP). A store and
forward packet switch which will accommodate up to 3 host
computers and 64 terminals.
c. HOST. A customer owned computer which is connected
to a host port on an IMP or TIP.
(1) LOCAL HOST. A host located within 30 feet of
an IMP or TIP.
(2) DISTANT HOST. A host which is more than 30 feet
but less than 2,000 feet from an IMP or TIP.
(3) VERY DISTANT HOST. A host which is located over
2,000 feet from an IMP or TIP and requires modems.
d. TERMINAL. A teletypewriter, CRT or similar unit
which is connected to a terminal port of a TIP.
e. INTERSWITCH TRUNKS. A circuit between packet
switches (e.g., IMPS and TIPS) which is used to pass
messages through the network.
f. ACCESS LINE. A circuit from a host computer or
terminal to an IMP or TIP. The circuit may be a local cable
or a transmission facility requiring modems.
g. BACKBONE. The switching nodes (e.g., IMPS - TIPS),
the communications lines interconnecting the nodes, and
the network control center.
h. SPONSOR. A DoD or U.S. Government Agency, which
qualifies as an ARPANET user is authorized to sponsor a
contractor or other non-government activity for access to
the ARPANET for the conduct of official U.S. Government
business.
4. DESCRIPTION: The ARPANET is an operational, computerized,
packet switching DoD digital network which provides a capa-
bility for terminals or geographically separated computers,
called Hosts, to communicate with each other. The Host
computers typically differ from one another in type, speed,
word length, and operating system. Each terminal or Host
computer is connected into the network through a local small
computer called an IMP or TIP. The complete network is formed
by interconnecting the IMP's through wideband communication
lines (50KB) supplied by common carriers. Each IMP and TIP
is programmed to receive and forward messages to the neighbor-
ing IMP's or TIP's in the network. During a typical Host to
Host operation, a Host passes a message to its IMP; the
message is passed from IMP to IMP through the network until
it finally arrives at the destination IMP, which passes it
along to the destination Host. A terminal (teletypewriter or
CRT) accesses the network through a Terminal Interface
Processor (TIP) and sends a message to a Host or another
Terminal. The terminal message passes through the network in
the same manner as a Host to Host message. The elements of the
network are the Interface Message Processors (IMP), Terminal
Interface Processors (TIP), interswitch trunks, access lines,
host computers and terminals.
5. RESPONSIBILITY FOR OPERATIONAL DIRECTION:
a. The Director, DCA, will control system engineering and
exercise operational direction over those operating elements of
ARPANET which are part of the backbone. ARPANET subscriber
equipment/terminals are non-backbone facilities. However,
ARPANET subscribers must be responsive to management instruc-
tions issued by the DCA.
b. Criteria and standards for interface are specified in
Report Number 1822, Interface Message Processor: Specifica-
tions for the Interconnection of a Host and an IMP (Bolt,
Beranek and Newman, April 1973). New criteria and standards
developed jointly by the DCA, the Military Services, and the
Defense agencies will be promulgated by the DCA. All sub-
scribers will meet ARPANET interface criteria.
c. The Director, DCA, on a continuing basis, will monitor
the effectiveness of ARPANET, evaluate those matters which
have major impact or will impact adversely on the network, and
direct action to alleviate or prevent such impact.
6. SUBSCRIBER ACCESS: The ARPANET is intended to be used
solely for the conduct of or in support of official U.S.
Government business.
a. DOD USERS - Subject to the availability of assets,
DoD activities will be connected to the ARPANET provided their
requirements are processed through normal communications
validating channels.
b. NON-DOD U.S. GOVERNMENT ACTIVITIES - Requests for
ARPANET service from non-DoD U.S. Government activities will
be considered by DCA on a case-by-case basis.
c. NON-GOVERNMENT U.S. ACTIVITIES - A DoD or other U.S.
Government activity authorized to use the network may sponsor
as a user, a non-government activity performing in contractural
support of the U.S. Government. Justification outlining
benefits to the U.S. Government for such access shalll be
provided to DCA by the sponsoring activity. Cost for network
services provided to non-government activities shall be
allocated to the sponsoring activity.
d. NON-U.S. ACTIVITIES - Non-U.S. activities will not be
directly connected to the ARPANET. Utilization of the ARPANET
may be provided through the facilities of an authorized user
provided the use is coordinated with DCA.
e. NON-COMPETITIVE BASIS - The ARPANET is an operational
DoD network and is not intended to compete with comparable
commercial service. Accordingly, before ARPANET service is
provided to any non-U.S. Government activity it must be
determined that adequate commercial service is not available.
f. PRIVACY - The proposed use of the ARPANET must not
be in violation of applicable information privacy laws.
7. PROCEDURE:
a. U.S. Government activities requesting ARPANET service
must apply to the Director, Defense Communications Agency,
ATTN: ARPANET Management Branch, Code 535. The format for
the application is at enclosure 1.
b. A non U.S. Government activity must have a U.S.
Government activity acting as a sponsor. Application for
sevice on the ARPANET must be submitted by the sponsoring
activity to Director, Defense Communications Agency, ATTN:
ARPANET Management Branch, Code 535. The application must
clearly state how the proposed service is in the best
interest of the U.S. Government, is essential to mission
fulfillment, does not violate information privacy laws, and
that adequate commercial service is not available.
c. DCA will evaluate the application and advise the
requesting activity of the disposition of their request with-
in thirty days. If the application is approved the notifica-
tion will include instructions for gaining access to the
ARPANET.
-------------------------------
∂30-SEP-75 0828 network site BBN
Date: 30 SEP 1975 1118-EDT
From: MCKENZIE at BBN-TENEX
Subject: Announcement of Demonstration - Forwarded on Behalf of DCA
To: NETWORK-LIAISON-GROUP:
cc: brownfield at ISI, walker at ISI
DCA has approved a demonstration of the ARPA Network at an international
computer conference to be held in Sao Paulo, Brazil during the last
week of October 1975. The demonstration will consist of dialing the
RML TIP and accessing an ARPA-sponsored Host, and will be conducted by
an ARPA representative from ISI. ARPA will effect the necessary
coordination with the designated Host.
-------------------------------
∂10-OCT-75 1504 FTP: host BBNB
Date: 10 OCT 1975 1736-EDT
From: DBROOKS at BBN-TENEXB
Subject: Address change for Bob Brownfield
To: NETWORK-LIAISON-GROUP:
cc: walker at ISI, dcacode535 at ISI, keeney,
cc: norton at OFFICE-1, watson, postel, lynch at SRI-AI,
cc: pine at OFFICE-1, hardy
The network mail address for Bob Brownfield of DCA has been
changed from BROWNFIELD@ISI to DCACODE535@ISI. Also
the U.S. Mail address listed in the ARPANET Directory has changed
to
Robert Brownfield
Defense Communications Agency
Code 535
Washington, D. C. 20305
Phone (202) 692-6175
Since Bob is the person to contact with any questions concerning
policies pertaining to the recent transfer of the ARPANET
management from ARPA to DCA, he would appreciate having
these address changes made known to as many users as possible.
Thanks,
Jake Feinler (Feinler@BBNB)
Network Information Center
------------------------------
∂13-OCT-75 0812 FTP: host BBNB
Date: 13 OCT 1975 1050-EDT
From: FEINLER at BBN-TENEXB
Subject: Addendum to Memo on Brownfield Address Change
To: NETWORK-LIAISON-GROUP:
cc: walker at ISI, roetter at OFFICE-1, norton at OFFICE-1,
cc: watson, engelbart at OFFICE-1, postel, lynch at SRI-AI,
cc: pine at OFFICE-1, hardy, retz at ISI
Steve Walker has asked me to point out that ARPA contractors should
go through ARPA on questions of ARPANET access and related
matters. ARPA funds all network access for its contractors and will handle
liaison with DCA for them. Network users not associated with ARPA should
contact DCA directly as previously stated.
Jake Feinler (Feinler@BBNB)
------------------------------
∂11-NOV-75 2242 FTP: host BBNB
Date: 12 NOV 1975 0140-EST
From: POSTEL at BBN-TENEXB
Subject: New Requests For Comments Available
To: [bbnb]<postel>Request-For-Comments.List:
RFCs 705 and 706 are now available at Office-1 the pathnames are:
<NETINFO>RFC705.TXT and <NETINFO>RFC706.TXT
files may be pulled from Office-1 via FTP using the username
NICGUEST and the password ARPA.
--jon.
---------------------------
1976
∂16-JAN-76 0051 FTP:POSTEL at BBN-TENEXB RFC 707 Available
Date: 16 JAN 1976 0344-EST
From: POSTEL at BBN-TENEXB
Subject: RFC 707 Available
To: [bbnb]<postel>Request-For-Comments.List:
RFC 707 "A High-Level Framework for Network-Based Resource Sharing" by
Jim White is now available on line at Office-1. The text file may be copied
via FTP from the pathname <NETINFO>RFC707.TXT. Office-1 allows the FTP login
username=NICGUEST and password=ARPA. The document is about 30 pages long.
--jon.
---------------------------
∂27-JAN-76 0910 FTP:FEINLER at BBN-TENEXB ARPANET Sponsors Meeting Minutes
Date: 27 JAN 1976 1105-EST
From: FEINLER at BBN-TENEXB
Subject: ARPANET Sponsors Meeting Minutes
To: NETWORK-LIAISON-GROUP:, SPONSORS-GROUP:
The message which follows this one contains the text of the first
ARPANET Sponsors Meeting Minutes. It is being distributed by
the NIC at the request of R. Brownfield of DCA for general
dissemination to ARPANET users.
The minutes run 25 pp. If you do not wish to print them out as
a message, ignore the next message from FEINLER@BBNB. The
minutes may also be FTPd from OFFICE-1 as
<NETINFO>SPONSORS-MEETING.TXT. To access by FTP, login to
OFFICE-1 as nicguest, password=ARPA.
Jake Feinler (FEINLER@BBNB)
-------------------------
∂28-JAN-76 2245 FTP:POSTEL at BBN-TENEXB RFC 708 Now Available
Date: 29 JAN 1976 0143-EST
From: POSTEL at BBN-TENEXB
Subject: RFC 708 Now Available
To: [bbnb]<postel>Request-For-Comments.List:
RFC 708 "Elements of a Distributed Programming System" by Jim White
is now available on line at Office-1 in the directory <NETINFO> under the
file name RFC708.TXT.
Files may be copied from Office-1 using FTP, Office-1 allows the FTP login
name NICGUEST and password ARPA to be used for this purpose.
the pathname again is <NETINFO>RFC708.TXT
The document is in excess of 30 pages.
--jon.
--------------------------------
∂25-FEB-76 2303 FTP:POSTEL at BBN-TENEXB RFC 712 Available
Date: 26 FEB 1976 1931-EST
From: POSTEL at BBN-TENEXB
Subject: RFC 712 Available
To: [bbnb]<postel>Request-For-Comments.List:
RFC 712 "A Distributed Capability Computing System (DCCS)" by
James E. Donnelley (JED@BBN) is now available on line at Office-1
as the file
<NETINFO>RFC712.TXT
Files may be copied from Office-1 using the FTP username NICGUEST and
password ARPA. This document is 30 printed pages.
--jon.
-------------------------------
∂08-APR-76 2250 FTP:POSTEL at BBN-TENEXB RFC 713 Available
Date: 9 APR 1976 0148-EST
From: POSTEL at BBN-TENEXB
Subject: RFC 713 Available
To: [bbnb]<postel>Request-For-Comments.List:
Request for Comments number 713 (NIC 34739) is now available on line at
Office-1.
Title: MSDTP -- Message Services Data Transmission Protocol
Author: Jack Haverty (JFH@MIT-DMS)
Length: 29 printed pages
Pathname: <NETINFO>RFC713.TXT at Office-1
Files may be copied from Office-1 via FTP by using the FTP username NICGUEST
and password ARPA.
--jon.
-----------------------------
∂29-APR-76 1425 FTP:MCKENZIE at BBN-TENEX IMP/Host Interfaces
Date: 29 Apr 1976 1652-EDT
From: MCKENZIE at BBN-TENEX
Subject: IMP/Host Interfaces
To: NETWORK-LIAISON-GROUP:
During the past several months we have been implementing changes to
the ARPANET IMP progam which will modify the IMP/Host interface as
documented in the December 1975 revision (and subsequent versions) of
BBN Report No. 1822, "Specifications for the Interconnection of a
Host and an IMP." We have characterized the changes to the IMP/Host
interface as backward-compatible (except for those special Hosts
using "Type 3" messages and those interacting with IMP statistics
packages, both of which require prior arrangement with the Network
Control Center in any case). However, we have recently discovered
two categories of problems, both caused by Host error or oversight,
which do not cause trouble with the current IMP system but which will
cause trouble with future systems. We believe that both of these
categories should probably be pointed out to everyone specifically.
They are:
1) Some PDP-11 systems use a bootstrap routine which, upon startup,
sends a large number (perhaps 28) of 16-bit messages to the IMP before
accepting any messages from the IMP (the PDP-11 program thinks these
are "NOP" messages, but they are obviously too short). Previously
the IMP was able to queue the requisite number of "Type 1" (error in
leader - too short) messages for delivery to the PDP-11; however,
changes in the structure of the IMP program necessitated by other
backward-compatibility problems makes it impossible for the IMP to
queue this many responses. Thus, the IMP and the Host get into a
deadlock situation which the IMP attempts to clear as described on
page 3-9 of BBN Report No. 1822; this in turn results in an endless
cycle of recurrances of the problem.
We expect to release the new IMP software which makes this change on
Tuesday, May 11 (it is already released to a few sites). If your
Host is a PDP-11 using this routine, or in fact if your Host is
accustomed to sending many messages to the IMP before accepting any
messages from the IMP, we urge you to make the necessary changes
prior to that time (or to communicate with the NCC if this would be
a hardship). In particular, the necessary changes to the PDP-11
routine are available from Jerry Burchfiel (BURCHFIEL@BBNA).
2) Some Hosts have expected all unused bits in IMP-to-Host messages
(e.g., "subtype" bits of Regular Messages) to be set to zero; some
Hosts have even expected unassigned bits (e.g., the "priority" bit -
bit 1) to be set to zero. Such assumptions have never been justified,
but even in the cases where they previously were valid they will be
invalid by the time the changes specified in the December Revision of
BBN Report No. 1822 are completed. We urge you to check whether your
Host makes any such unwarrented assumptions regarding the IMP-to-Host
Leader Formats, and to correct any cases which you discover.
Sincerely,
Alex McKenzie (for the Network Control Center)
-------------------------------
∂30-APR-76 2007 FTP:POSTEL at BBN-TENEXB RFC 714 Available
Date: 30 Apr 1976 2307-EDT
From: POSTEL at BBN-TENEXB
Subject: RFC 714 Available
To: [bbnb]<postel>Request-For-Comments.List:
Network Working Group Request for Comments number 714 is now available
in the online text file <NETINFO>RFC714.TXT at Office-1. The title
is "A Host/Host Protocol for an ARPA-type Network." The author is
Alex McKenzie of BBN-NCC. The document is 43 printed pages.
Files may be copied from Office-1 via FTP. The FTP username NICGUEST
and password ARPA allow access for reading public files.
Some people have suggested that this type of notice could be supplanted
by a notice to a per organization mailbox with intraorganization
distribution handled by each organization. If you wish to be notified in
that manner please sndmsg me the name of the orginazation mailbox to
replace your mailbox on my distribution list.
--jon.
-----------------------------
∂31-MAY-76 2351 FTP:POSTEL at BBN-TENEXB Request for Comments 716
Date: 1 Jun 1976 0239-EDT
From: POSTEL at BBN-TENEXB
Subject: Request for Comments 716
To: [bbnb]<postel>Request-For-Comments.List:
Request for Comments number 716 is now available. the note is titled
"Interim Revision to Appendix F of BBN Report 1822" and is authored by
David Walden and Joel Levin. The note is one and one half text pages in
length. The note is available as the online text file
<NETINFO>RFC716.TXT at Office-1
Files may be copied from Office-1 using the FTP username NICGUEST and
password ARPA.
This note is of special interest to persons concerned with very-distant
host-imp interfaces.
--jon.
----------------------------
∂23-JUN-76 1518 FTP:PLEASANT at RUTGERS-10 AN ATTEMPT AT SYNTHESIZED SPEECH
Date: 23 Jun 1976 (Wednesday) 1753-Est
From: PLEASANT at RUTGERS-10
Subject: AN ATTEMPT AT SYNTHESIZED SPEECH
To: ALAN at USC-ISI, BARKALOW at LL-, CERF at USC-ISI,
To: DAVIDSON at I4-TENEX, FEINLER at BBN-TENEXB, SWG at MIT-DMS,
To: HARDY at BBN-TENEXB, HEARN at UTAH-10, KIRSTEIN at USC-ISI,
To: KELLY at BBN-TENEX, KING at CMU-10B, SCRL at USC-ISI,
To: WALKER at USC-ISI, TK at MIT-AI, NETWORK-LIAISON at MIT-ML,
To: JAF at SU-AI, JBR at SU-AI, RUBIN at BBN-TENEX,
To: WOODS at BBN-TENEX, BRUCE at BBN-TENEX, KANODIA at MIT-MULTIC,
To: KUO at USC-ISI, OGDEN at UTAH-10, SEGOVICH at BBN-TENEX,
To: WOLFE at UCLA-CCN, FRANKLIN at HARV-10, ROB at SDC-LAB,
To: HASKINS at BBN-TENEX
THE FOLLOWING IS THE PAPER THAT I AND THREE OTHER STUDENTS
HAVE WRITTEN CONCERNING THE VOTRAX SPEECH SYNTHESIZING PROGRAM
THAT WAS WRITTEN HERE AT RUTGERS UNIVERSITY. IF YOU HAVE ANY
QUESTIONS AFTER READING THE PAPER PLEASE DO NOT HESITIATE TO
DROP SOME MAIL OFF AT PLEASANT@RUTGERS-10.
MEL PLEASANT
ENCLOSED: AN ATTEMPT AT SYTHESIZED SPEECH
AN ATTEMPT AT SYNTHISIZED SPEACH
Roy Marantz,
Mel Pleasant,
Dennis Meade
for Prof. W. Fabens
02:198:412
May 24, 1976
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 1
INTRODUCTION
This paper is the result of a one semester project done
by three students at Rutgers University under the direction
of Prof. W. Fabens from the Computer Science department of
Rutgers University. The project started with a goal of
simply utilizing the VOTRAX [1] unit in some useful way.
There were two types of alternatives avalible to us. The
table lookup method and the letter - to - phone translation
method. We chose the second type because of its generality
in handling a much larger segment of the English language.
Because of its greater availability and our time limit, we
chose to implement a letter-to-phone translation method
descibed by McIlroy [2] of Bell Laboratories. In addition
to his program, we have implemented various features which
we think make the output easier and more acuratly produced.
Among these are: special number handling, special prefix
translation , and simple stress of sylables in words.
Because of the short time needed to be able to understand
the output, we have made this program usable as a general
output replacement for printed text. This is finding some
use in Computer Assisted Instruction, games, and naration of
------------------------
1. VOTRAX, Vocal Interface Division, Federal Screw Works,
500 Stephenson Highway,Troy, Michgan, 48084.
2. M.D. McIlroy, "Synthetic English Speech by Rule," Bell
Telephone Laboratories, March 1974.
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 2
INTRODUCTION
graphical output. This program will be useful where ever
printed output is inconvienent such as remedial reading or
the like.
The basic program, ala McIlroy, is a letter-phrase to
phone translator with three parts: word lookup,
preprosessing of suffixes, and rule application. To these
we added three additional sections most recently used word
lookup, special number handling, prefix pretranslation, and
word stress. A simplified flow diagram of the program is
given in figure 1.
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 3
(figure 1)
------------
START
------------
<----------------------------------
------------------
GET INPUT LINE
------------------
*
* *
* * YES --------------
* COMMAND? *-----------> DO COMMAND -->
* * --------------
* *
*
NO
------------------>
**
* MORE * NO
* WORDS? *-------------------------------
* *
**
YES
------------------
BREAK OFF WORD
------------------
------------------
HANDLE SPECIAL
NUMBERS
------------------
*
* *
* IN * YES
* EXCEPTION *----------------
* TABLES? *
* *
*
NO
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 4
(figure 1 continued)
-------------
TRANSLATE
PREFIXES
-------------
-----------------
MARK SUFFIXES
-----------------
-----------------------
APPLY LETTER STRING
TO PHONE RULES
-----------------------
<-----------------------
----------------------
APPLY STRESS RULES
----------------------
-----------------------
TRANSLATE PHONES TO
VOTRAX FORM AND
OUTPUT
-----------------------
---------------------
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 5
SPECIAL NUMBER HANDLING
The special number handler is a feature which will
translate certain well known number forms into their spoken
equivalents. These number forms are:
TYPE EXAMPLE
standard numbers 98309
dollars and cents $32.58
dates 5/26/76
time 3:46:21
These forms will be spoken as (using previous examples):
ninety 8 thousand 3 hundred nine
thirty 2 dollars and fifty 8 cents
may twenty 6 nineteen seventy 6
3 forty 6 and twenty 1 seconds
Note that the preprocessor recognizes single digits;
therefore, single digits are not translated to their English
word equivalents.
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 6
STRESS
The stressing of individual words within the system is
accomplished by a function known as STRESS. This function
is a partial implementation of stress rules which appear in
ENGLISH STRESS (HALLE AND KEYSER,1971). The rules have been
adapted for use in this function and appear below. Input to
STRESS consists of a string of consonant and vowel phones
representing the phonetic values of an English word.
STRESS RULES
MAIN STRESS RULE
(1a) V --> [1ST STRESS] /
[X---C<0>((V<NT>C<0,1>)V<NT>C<0>)]
(1b) V --> [1ST STRESS] /
[X---C<0>(V<NT>C<0,1>)V<1ST STRESS>C<0>y]
ALTERNATING STRESS RULE
(2) V --> [1ST STRESS] /
[X---C<0>VC<0>V<1ST STRESS>C<0>]
AUXILIARY REDUCTION RULE - III
(3) V --> [3RD STRESS] /
[X---C<0>(V<NT>C<0,1>)VC<0>V<1ST STRESS>Y]
AUXILIARY REDUCTION RULE - I
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 7
STRESS
(4) V --> [NO STRESS] /
[XV<1ST STRESS>C<0>---C<0>VY]
TENSING RULE - II
(5) V --> [TENSE] /
[X---]
Explanation of symbols:
X,Y - Represent any combination of vowel
and consonant phones or a null
string.
C - Represents a consonant phone string
or a null string.
V - Represents a vowel phone string.
C<N,M> - N is the fewest number of conso-
nants from which the consonant
phones of C are derived. M is
the greatest. If M is absent,
there is no upper limit.
V<1ST STRESS> - Vowel phone string must have
been given primary stress.
V<NT> - Vowel phone string must be derived
from a non-tense vowel.
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 8
STRESS
y - Represents the letter 'y'
() - Indicate that this portion of a
rule may be dropped and then the
rule re-applied.
Application of the Rules
Stressing is accomplished by raising the pitch on a
vowel phone. The rules are applied sequentially. However,
in some cases STRESS will skip a rule which is
inappropriate. For example, if in attempting to apply the
Main Stress Rule the function does not place primary stress
on the last vowel phone string in a word, it will skip the
Alternating Stress Rule which requires primary stress on the
last vowel phone string. Tensing Rule - II is implemented
implicitly by treating final tense vowel phone strings as
non-tense. Placement of primary stress on a vowel phone
string causes the stress on any other string with primary
stress to be reduced.
Limitations of STRESS
The number of rules from ENGLISH STRESS which have been
implemented in STRESS is limited by the number (4) of pitch
levels offered by the VOTRAX device. STRESS is also limited
by its input, a string of phones. In some cases, the stress
rules must be applied before a vowel is tensed. However,
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 9
STRESS
vowels have already been tensed by the the time they reach
STRESS. In spite of these limitations, STRESS properly
accents a large class of words.
For an understanding of the suffix marker and the
letter - to - phone rules, I am assuming a familiarity with
McIlroy's article [2]. We have made minor changes in these
sections as necessitated by the prefix handling and some
hardware problems to be described later. The suffix marker
still marks only suffixes that are treated as if they were
final e's in relation to preceeding vowels. We have done
some more suffix checking in the prefix translator in order
to help distinguish true prefixes from words that begin with
prefix strings but are in actuality part of the word. (i.e.
re as in rectal)
The system was designed with as little special hardware
being needed as posible. As can be seen in figure 2 the
only special hardware used is the VOTRAX phone synthesiser
[1]. This can be connected to any kind of terminal at a
great variaty of speeds. Especialy for debuging, but also
for general use we prefer a upper-lower case terminal that
!AN ATTEMPT AT SYNTHISIZED SPEACH Page 10
HARWARE
we run at 1200 baud. The program works in real time, with a
minor adjustment (see the section on phone - to - votrax
translation), at any of the available speeds.
∂02-JUL-76 0945 FTP:POSTEL at USC-ISIC RFC 717 and 718 now available
Date: 2 JUL 1976 0944-PDT
From: POSTEL at USC-ISIC
Subject: RFC 717 and 718 now available
To: [isic]<postel>Request-For-Comments.List:
Two RFCs are now available at Office-1
RFC 717 "Assigned Network Numbers" by Jon Postel (2 pages)
RFC 718 "Comments on RCTE from the TENEX Implementation Experience"
based on the TENEX 1.34 doucumentation (2 pages)
The file names are:
<NETINFO>RFC717.TXT and <NETINFO>RFC718.TXT at OFFICE-1
Files may be copied from Office-1 via FTP using the FTP username NICGUEST
and password ARPA.
Also please note the following changes of network addresses:
Jon Postel is now POSTEL@ISIC
Jake Feinler is now FEINLER@OFFICE-1
--jon.
---------------------------------
∂07-JUL-76 0813 FTP:MCKENZIE at BBN-TENEXE Scheduled IMP Software Maintenance PLUS EXTRA INFORMATION
Date: 7 Jul 1976 1113-EDT
From: MCKENZIE at BBN-TENEXE
Subject: Scheduled IMP Software Maintenance PLUS EXTRA INFORMATION
To: NETWORK-LIAISON-GROUP:
This is a reminder that Network Software Maintenance is scheduled
between the hours of 0700 and 0900 (Eastern Time) every Tuesday,
and a notice that release of a new system is scheduled for Tuesday,
13 July 1976.
Yesterday, 6 July, this new system was released to approximately half
of the network nodes, mostly those in the northeast and midwest. Next
Tuesday, 13 July, we expect that the system should be released to the
remainder of the network nodes. This system implements the changes
to the IMP/Host interface which permit Hosts to use the expanded
leader format as documented in BBN Report 1822, "Specifications for
the Interconnection of a Host and an IMP", December 1975 revision.
The old style unexpanded leader formats are also supported by the
IMP, and will continue to be so for the indefinite future. The
change is designed to be backward-compatible, so that there should
be minimal impact on the Hosts. Nevertheless, there are three potential
problem areas which eveyone should be aware of, as follows:
1) The Host informs the IMP whether it chooses to use expanded or
unexpanded leaders by the type of NOP message it sends the IMP
during the establishment of IMP/Host communication. The IMP sends
the Host both types of NOP messages during establishment of
IMP/Host communication to indicate to either type of Host that
communication may begin (see RFC 704, as well as Section 3.2 of
Report 1822). A "new-style" NOP will look to an "old-style" Host
like a Type 15 IMP-to-Host message, which has previously been
undefined. Old-style Hosts may safely discard these messages.
2) Previous descriptions of the IMP software have listed some bits or
bit patterns of the IMP-to-Host leader as "unassigned". A few
Hosts have taken advantage of the fact that these bits were
previously "always" set to zero, a fact which should never have
been counted on and is not true (for example, see my message
to Liaisons of 29 April 1976, as well as Appendix A of Report 1822).
A particular example is the first bit of the IMP-to-Host leader,
which is now used to report to the receiving Host the sender-assigned
priority of the message, but which was previously "unassigned".
3) The size of the new code reduces the number of packet reassembly
buffers available in the IMP by 6. This fact is most likely to have
an adverse effect at IMPs where VDH code is resident in "IMP core";
there are four such sites, namely NUC, CCA, Eglin, and SCRL.
Sincerely,
Alex McKenzie (for the Network Control Center)
---------------------------------
∂22-JUL-76 1653 FTP:POSTEL at USC-ISIC RFC 719 & Cerf relocation
Date: 22 JUL 1976 1555-PDT
From: POSTEL at USC-ISIC
Subject: RFC 719 & Cerf relocation
To: [isic]<postel>Request-For-Comments.List:
This is to announce the availability of RFC 719 online at Office-1.
The title is "Discussion on RCTE" and the document is 2 text pages. Files may
be copied from Office-1 via FTP by using the FTP user name NICGUEST and
password ARPA. The document is in the file <NETINFO>RFC719.TXT.
Vint Cerf is leaving Stanford University to join the staff at the ARPA-IPT
office. Vint's new address is:
DARPA/IPTO
1400 Wilson Blvd.
Arlington, VA. 22209
(202) 694-5922
Vint's network address remains CERF@ISI.
--jon.
----------------------------------------
∂06-AUG-76 1040 FTP:POSTEL at USC-ISIC RFC 720 Available
Date: 6 AUG 1976 1039-PDT
From: POSTEL at USC-ISIC
Subject: RFC 720 Available
To: [isic]<postel>Request-For-Comments.List:
Network Working Group Request for Comments 720 is now available at
Office-1 as the file <NETINFO>RFC720.TXT The document is titled
"Address Specification Syntax for Network Mail" the Author is Dave
Crocker of USC and the document is 4 pages long.
Files may be copied from Office-1 via FTP by using the FTP username
NICGUEST and password ARPA.
--jon.
--------------------------------------
∂03-SEP-76 1300 FTP:POSTEL at USC-ISIC RFC 721 Available
Date: 3 SEP 1976 1300-PDT
From: POSTEL at USC-ISIC
Subject: RFC 721 Available
To: [isic]<postel>Request-For-Comments.List:
Network Working Group / Request for Comments 721 is now available on line
at Office-1. The RFC is titled "Out-of-Band Signals in a Host-to-Host Protocol"
and is authored by Larry Garlick. The document is 7 text pages in length.
The file may be copied from Office-1 via the File Transfer Protocol. Office-1
allows the use of the FTP login NICGUEST with password ARPA for this purpose.
The pathname of the file is <NETINFO>RFC721.TXT
--jon.
--------------------------------------
∂21-SEP-76 1000 FTP:POSTEL at USC-ISIC RFC 722 Available
Date: 21 SEP 1976 0958-PDT
From: POSTEL at USC-ISIC
Subject: RFC 722 Available
To: [isic]<postel>Request-For-Comments.List:
Network Working Group Request for Comments number 722 is now available at
Office-1. The title is "Thoughts on Interaction in Distributed Services".
The author is Jack Haverty of MIT-DMS. The document is 20 text pages long.
The online pathname is <NETINFO>RFC722.TXT at Office-1.
Office-1 allows copying of public files via FTP using the username
NICGUEST and password ARPA.
--jon.
----------------------------------------
∂21-SEP-76 1217 FTP: Kanodia at MIT-Multics Liaison change at MIT-Multics
From: Kanodia at MIT-Multics
Date: 09/21/76 1506-edt
Subject: Liaison change at MIT-Multics
To:
liaison-sndmsg.txt.al
Effective October 1, 1976, MIT-Multics will have a new
Network Liaison. On that date, George Williams of MIT
Information Processing Services will take over the task of
Liaison from Raj Kanodia of the MIT Laboratory for Computer
Science, who is leaving MIT.
George will be ready, willing and able to take over the
traditional Liaison functions: fielding user queries, handling
requests for information and documentation, etc. In addition,
since the Liaison function will be transferred from the
Laboratory for Computer Science, a research organization, to
Information Processing Services, the organization which runs the
Multics service at MIT, George will be particularly able to
answer questions regarding software packages available on MIT's
Multics, access to the system, prices for services, etc.
George can be reached by telephone at (617) 253-3735, or by
ARPANET mail as "GTWilliams at MIT-Multics" or "Liaison at
MIT-Multics" (Please note that MIT-Multics is now Host 6 rather
than Host 44). His U.S. Mail address is:
George T. Williams
MIT Information Processing Services
Room 39-421
77 Massachusetts Avenue
Cambridge, MA 02139
--------------------------------------
1977
∂08-Mar-77 2349 FTP:POSTEL at USC-ISID RFC Announcement
Date: 8 Mar 1977 2352-PST
From: POSTEL at USC-ISID
Subject: RFC Announcement
To: [isid]<postel>Request-For-Comments.List:
Request for Comments 726 titled "Remote Controlled Transmission and
Echoing Telnet Option" is now available online at Office-1. This 16 page
document updates and clarifies the previously available RCTE
specification (NIC 19859). RFC 726 is now to be used as the official
specification of the RCTE Telnet Option. The pathname for this file is:
<NETINFO>RFC726.TXT at Office-1
Files may be copied from Office-1 via FTP using the FTP user name
NICGUEST and password ARPA.
- - - - -
This month i am leaving SRI-ARC to join the staff of ISI. My US Mail
address will be:
Information Sciences Institute
4676 Admiralty Way
Marina del Rey, California 90291
The phone number:
(213) 822-1511
And principal mailbox:
POSTEL@ISIB
--jon.
------------------------------------
∂10-Mar-77 1233 FTP:JZS at CCA Datacomputer Version 3 Users' Guide
Date: 10 MAR 1977 1533-EST
From: JZS at CCA
Subject: Datacomputer Version 3 Users' Guide
To: DATACOMPUTER USERS:, DFTP LIAISONS:, SEISMIC-USERS:,
To: SPONSORED-RESEARCH-DIV-STAFF:, ACCAT:, DDBS:
This document is currently available on the Datacomputer, via DFTP,
by attaching to COMMON>DATACOMPUTER and retrieving the file named
VERSION3.GUIDE.
------------------------------------
∂28-Apr-77 1503 FTP:POSTEL at USC-ISIB New RFCs Available
Date: 28 APR 1977 1504-PDT
From: POSTEL at USC-ISIB
Subject: New RFCs Available
To: [isie]<postel>Request-For-Comments.List:
Three RFCs are now online and available for copying from Office-1.
RFC 725 "An RJE Protocol for a Resource Sharing Network"
John Day and Gary Grossman 27 text pages
pathname: <NETINFO>RFC725.TXT
RFC 727 "Telnet Logout Option"
Mark Crispin 3 text pages
pathname: <NETINFO>RFC727.TXT
RFC 728 "A Minor Pitfall in the Telnet Protocol"
John Day 1 text page
pathname: <NETINFO>RFC728.TXT
These files may be copied from Office-1 using the File Transfer Protocol. The
Network Information Center makes available the FTP user name NICGUEST with
password ARPA for this purpose.
--jon.
-----------------------------------
∂13-May-77 1812 FTP:POSTEL at USC-ISIE RFCs 724 & 729 Available
Date: 13 May 1977 1811-PDT
From: POSTEL at USC-ISIE
Subject: RFCs 724 & 729 Available
To: [isie]<postel>Request-For-Comments.List:
Request for Comments 724 is now available online at Office-1.
The title is: "Proposed Official Standard for the Format of ARPA Network
Messages". The authors are: Ken Pogran, John Vittal, Dave Crocker, and
Austin Henderson. The document is 36 text pages long.
This important document proposes standards to be used in the sndmsg
headers that may have implications on many current mail processing
programs, and may impact the kinds of messages system to be built in
the future.
Please send any comments and criticisms to any of the
authors of this RFC by 15 June 1977. It is planned that the
standard will be officially adopted by 1 September 1977, with
hosts expected to accept its syntax by 1 January 1978.
The document is available from Office-1 and may be copied via FTP.
From your host you may connect to the Office-1 FTP server and access
the document by first supplying the FTP username NICGUEST and password
ARPA. The pathname of the document is:
<NETINFO>RFC724.TXT
Also available at Office-1 is RFC729 titled "Telnet Byte Macro Option"
authored by Dave Crocker. The pathname for this file is:
<NETINFO>RFC729.TXT
This document 3 pages long and may be copied from Office-1 using the
procedure described above.
--jon.
--------------------------------------
∂20-May-77 1902 FTP:POSTEL at USC-ISIE RFC 730 Available
Date: 20 May 1977 1902-PDT
From: POSTEL at USC-ISIE
Subject: RFC 730 Available
To: [isie]<postel>Request-For-Comments.List:
Request for Comments number 730 is now available online at Office-1. The
memo is titled "Extensible Field Addressing" and is Authored by Jon Postel.
The memo is 5 text pages long. Files may be copied from Office-1 via FTP.
The Network Information Center provides the FTP username NICGUEST and
password ARPA for this purpose.
The pathname of the document is:
<NETINFO>RFC730.TXT
--jon.
-------------------------------------
∂02-Jun-77 2254 FTP:FEINLER at OFFICE-1 Switch from Office-1 to SRI-KL
Date: 2 JUN 1977 2231-PDT
From: FEINLER at OFFICE-1
Subject: Switch from Office-1 to SRI-KL
To: [OFFICE-1]<NETINFO>nlg.txt:
cc: feedback
Please note that effective 5-June-77 all users of OFFICE-1 (43 dec, 53
oct) will be transferred to the SRI-KL (66 dec, 102 oct) machine.
OFFICE-1 will leave the net shortly thereafter (exact date not known).
NIC files will also be transferred to the SRI-KL, and mail for the NIC
should be addressed to FEINLER@SRI-KL. The NIC phone remains the same,
(415) 326-6200 ext 3695.
NIC/Query will be off the net until further notice so that we can adapt
it to the TOPS-20 system. However, NIC reference files, such as
<NETINFO>HOSTS.TXT, <NETINFO>LIAISON-SNDMSG.TXT, RFCs, Protocol files,
etc., will be online and may be FTPd to your local host using the
'anonymous' login convention.
We regret any inconvenience this might cause, and will try to make the
transition as quickly as possible.
Regards,
Jake
-------------------------------------
∂29-Jun-77 1852 FTP:POSTEL at USC-ISIE RFC 731 Available
Date: 29 Jun 1977 1849-PDT
From: POSTEL at USC-ISIE
Subject: RFC 731 Available
To: [isie]<postel>Request-For-Comments.List:
Request for Comments number 731 is now available on line at SRI-KL. The
document is titled "Telnet Data Entry Terminal Option" and is authored by
John Day. The document is 28 text pages long.
The document may be copied from SRI-KL using the FTP username Anonymous
and password Guest. The pathname of the document file is:
<NETINFO>RFC731.TXT
Please note the change of location for this and all the other
files maintained online by the Network Information Center. All the files
formerly available in the <NETINFO> directory at Office-1 are now available
in the <NETINFO> directory at SRI-KL.
--jon.
-------------------------------------
∂15-Sep-77 0931 FTP:Feinler at SRI-KL TELNET Protocol
Date: 15 Sep 1977 0740-PDT
From: Feinler at SRI-KL
Subject: TELNET Protocol
To: [SRI-KL]<FEINLER>liaison-sndmsg-6-77:
I have been asked to transmit this message to you on behalf
of the Defense Communications Agency.
Jake (FEINLER@SRI-KL)
*************************************************************
To: Host Liaison and ARPANET Sponsors
Subject: TELNET Protocol
On 1 Nov 77 at the request of this office the NCC will remove
"Old TELNET" Protocol from all TIPs. It is being removed in
order to release some TIP storage for oher uses. We understand
that most network hosts have tracked the evolution of TELNET
over the last several years and are already operating in the
new mode. A few may have to update their programs.
Jon Postel (POSTEL@ISIB) offers the following summary of the
differences between old TELNET and new:
There are a few incompatibilities between old and new telnet.
The main one is in the exchange of control information,
especially the negotiation of options. If interactive
exchanges more flexible than line at a time are to be used it
will be necessary to implement the "echo" and "supress go ahead"
options.
The new telnet implementations are to establish communication
via socket 23 (27 octal). The current use of socket 1 by old
telnet will be discontinued, and socket 1 may eventually be
assigned to completely different protocol.
--jon.
The 'new' TELNET Protocol and many of the options are documented
in the ARPANET Protocol Handbook, NIC 7104, April 1976, pp 53-161.
All of these protocols are also available online from the NIC.
In addition, new TELNET options not listed in the Protocol
Handbook are also available from the NIC. These can be FTPd from
SRI-KL (66 dec) using the pathnames cited below and the 'anonymous'
login convention.
Please feel free to contact me if you have any problems with this
change.
Regards,
Maj. Raymond Czahor
DCA Code 535
DCACODE535@ISI
(202) 692-6175
******
TELNET-PROTOCOLS
Basic Specifications
TELNET PROTOCOL SPECIFICATION
pathname = <netinfo>nic18639.txt
TELNET SPECIFICATIONS
pathname = <netinfo>nic18640.txt
Options
TELNET BINARY TRANSMISSION OPTION
pathname = <netinfo>nic15389.txt
TELNET ECHO OPTION
pathname = <netinfo>nic15390.txt
TELNET RECONNECTION OPTION
pathname = <netinfo>nic15391.txt
TELNET SUPPRESS GO AHEAD OPTION
pathname = <netinfo>nic15392.txt
TELNET APPROXIMATE MESSAGE SIZE NEGOTIATION OPTION
pathname = <netinfo>nic15393.txt
REVISED TELNET STATUS OPTION
pathname = <netinfo>rfc651.txt
TELNET TIMING MARK OPTION
pathname = <netinfo>nic16238.txt
REMOTE CONTROLLED TRANSMISSION AND ECHOING TELNET OPTION
pathname = <netinfo>nic19859.txt
TELNET OUTPUT LINE WIDTH OPTION
pathname = <netinfo>nic20196.txt
TELNET OUTPUT PAGE SIZE OPTION
pathname = <netinfo>nic20197.txt
TELNET OUTPUT CARRIAGE RETURN DISPOSITION
pathname = <netinfo>rfc652.txt
TELNET OUTPUT HORIZONTAL TABSTOPS OPTION
pathname = <netinfo>rfc653.txt
TELNET OUTPUT HORIZONTAL TAB DISPOSITION
pathname = <netinfo>rfc654.txt
TELNET OUTPUT FORMFEED DISPOSITION OPTION
pathname = <netinfo>rfc655.txt
TELNET OUTPUT VERTICAL TABSTOPS OPTION
pathname = <netinfo>rfc656.txt
TELNET OUTPUT VERTICAL TAB DISPOSITION OPTION
pathname = <netinfo>rfc657.txt
TELNET OUTPUT LINEFEED DISPOSITION
pathname = <netinfo>rfc658.txt
TELNET EXTENDED ASCII OPTION
pathname = <netinfo>nic32964.txt
TELNET EXTENDED OPTIONS LIST OPTION
pathname = <netinfo>nic16239.txt
TELNET LOGOUT OPTION
pathname = <netinfo>rfc727.txt
TELNET BYTE MACRO OPTION
pathname = <netinfo>rfc729.txt
TELNET DATA ENTRY TERMINAL OPTION
pathname = <netinfo>rfc732.txt
----------------------------------
∂21-Sep-77 1603 BPM ∂21-Sep-77 1217 FTP:MIMNO at BBN-TENEXE binary mode on TIPs
To: ME, JBR
Date: 21 Sep 1977 1507-EDT
From: MIMNO at BBN-TENEXE
Subject: binary mode on TIPs
To: BPM at SU-AI, Geoff at SRI-KA
cc: Mimno
I have found bug/oversight in the new telnet code;
binary mode (both in and out) was not being cleared
when the connection closed. I have a patch that
fixes this which will be going out soon. It requires
reloading so will have to happen at night- probably
within a few days. I will get it to Ames TIP early
on; if you use others, let me know and I will give
them priority also.
To summarize the way it is:
Old Telnet mode binary will remain the same. Binary
is considered a feature of the device. For a non-hunting
port, binary (in or out) remains in effect until an
explicit command is given to end binary; for a hunting port,
reseting, hanging-up, or turning off also end binary.
In New Telnet, binary is considered a feature of the connection
and is not in effect unless a connection is open and
the TIP and Host have negotiated the binary option.
The TIP does have an additional flag indicating
whether the port "desires" binary mode. Like Old
Telnet Binary, this flag does not reset for non-hunting
ports unless explicitly turned off. When the binary command
is given, the TIP sets the "desire binary" flag and if
a connection is open, also initiates the option negotiation.
When the connection closes, the TIP turns off "actual" binary
but remembers that the port "desires" binary and will
accept a future binary request from a Host. (The TIP
itself won't initiate binary unless a new command is given
after the connection opens.) The intent is to enable
a host to exert control ( eg. on receipt of a
terminal type command) without making difficulties for
unwitting users (such as the problems you've had with
unusable dial-up).
I will send another message when Ames-TIP gets the patch.
Let me know if you want to know about othr TIPs; they'll
all get it eventually.
THis should solve your problem. When the modem hangs up, the
connection woill close and binary will go away. If it
doesn't, let me know.
Please forward this message to anyone else you think
should get it.
Thanks,
Nancy
--------------------------------------
∂08-Oct-77 2213 FTP:POSTEL at USC-ISIB RFC 734 available
Date: 8 OCT 1977 2213-PDT
From: POSTEL at USC-ISIB
Subject: RFC 734 available
To: [isie]<postel>Request-For-Comments.List:
RFC number 734 is now available on line at SRI-KL in directory <NETINFO>.
The title of this RFC is "SUPDUP Protocol", the author is Mark Crispin of
SU-AI. The RFC is 14 text pages in length. The pathname for access via FTP
is:
<NETINFO>RFC734.TXT at SRI-KL
The Network Information Center makes available this online repository and
provides for access to these file via FTP thruogh the FTP username
NICGUEST and password ARPA.
--jon.
-----------------------------------------
∂04-Nov-77 0202 FTP:POSTEL at USC-ISIB New RFCs Available
Date: 3 NOV 1977 2312-PST
From: POSTEL at USC-ISIB
Subject: New RFCs Available
To: [isie]<postel>Request-For-Comments.List:
The following new Requests for Comments are now available online from
the Network Information Center:
RFC 735 "Revised Telnet Byte Macro Option" by D. Crocker and R.
Gumpertz (5 pages)
pathname: <NETINFO>RFC735.TXT
RFC 736 "SUPDUP Telnet Option" by M. Crispin (2 pages)
pathname: <NETINFO>RFC736.TXT
RFC 737 "FTP Extension: XSEN" by K. Harrenstien (1 page)
pathname: <NETINFO>RFC737.TXT
RFC 738 "Time Server" by K. Harrenstien (1 page)
pathname: <NETINFO>RFC738.TXT
Files may be copied from the NIC library at host SRI-KL via FTP. The
FTP username NICGUEST and password ARPA will allow copying of public
access files.
Also of interest may be the proceedings of the Fifth Data
Communications Symposium (27-29 September 1977, Snowbird, Utah).
Among the papers of particular significance to ARPANET protocol
hackers are:
"The ARPANET Telnet Protocol: Its Purposes, Principles,
Implementation, and Impact on Host Operating System Design" by J.
Davidson, W. Hathway, J. Postel, N. Mimno, R. Thomas, & D. Walden.
"A Server Host System on the ARPANET" by R.T. Braden.
"Issues in Message Technology" by D.A. Henderson & T.H. Myer.
"Issues in Transnet Packetized Voice Communication" by D. Cohen.
"Encryption-Based Protection for Interactive User/Computer
Communication" by S.T. Kent.
"Reliable Host-to-Host Protocols: Problems and Techniques" by L.
Garlick R. Rom & J. Postel.
The proceedings are available from both ACM and IEEE.
ACM Order Department
1133 Avenue of the Americas
New York, New York 10036
IEEE
345 East 47th Street
New York, New York 10017
IEEE Computer Society
5855 Naples Plaza, Suite 301
Long Beach, California 90803
The IEEE Catlog Number is 77CH1260-9C.
--jon.
--------------------------------------
∂22-Nov-77 2106 FTP:POSTEL at USC-ISIB RFCs Available
Date: 22 NOV 1977 2106-PST
From: POSTEL at USC-ISIB
Subject: RFCs Available
To: [isie]<postel>Request-For-Comments.List:
Four new Requests for Comments are now available from the Network
Information Center's online Library:
RFC 733 "Standard for the Format of ARPA Network Text Messages" by
D. Crocker, J. Vittal, D. Henderson, and K. Pogran (38 pages).
This is the final version of the standards to be used in
ARPANET mail headers. There is an implication that current
mail processing programs must to conform to this standard in
the near future. This is likely to require changes to most of
these programs.
RFC 739 "Assigned Numbers" by J. Postel (11 pages).
This is a summary of the link and socket numbers assigned for
normal and experimental use of the ARPANET, and of numbers
assigned for use in internetwork experiments conducted by the
ARPA research community.
RFC 740 "NETRJS Protocol" by R. Braden (19 pages).
This is a restatement of the UCLA CCN NETRJS protocol,
collecting and updating in one document the information from a
set old RFCs.
RFC 741 "Specifications for the Network Voice Protocol (NVP)" by
D. Cohen (34 pages).
This is a restatement of the Network Voice Protocol, which has
been in use for several years, but not previously documented in
RFC form.
These documents may be obtained via the File Transfer Protocol. The
NIC makes available the FTP username NICGUEST and password ARPA for
this purpose. The FTP pathnames are:
<NETINFO>RFC733.TXT
<NETINFO>RFC739.TXT
<NETINFO>RFC740.TXT
<NETINFO>RFC741.TXT
--jon.
-------